I agree regarding plural form. Should examples for course entity be changed accordingly?

We don't need to strictly follow the subsystems names here.
However, in the example of course, /courses/<courseid>/view sounds not correct, as you are only going to ever look at a singular course. So I think in this case singular is the way to go.
Not sure how we make the docs clearer though.

At the moment the component resolution is automatic based on the location of the class and we automatically normalise it.

If we want to do something different then we'll have to work out the best way of doing so and in which situations.

However, in the example of course, /courses/<courseid>/view sounds not correct, as you are only going to ever look at a singular course. So I think in this case singular is the way to go.

Yeah, it is sounds not correct in individual scenario, unless one see it as query "select <courseid> from courses". Thinking in broader context, what will be the endpoint for querying list of courses? Different /courses path or /course/list action? Something better to consider while we are at early stage I guess :)

With regard to this "tip", to avoid contradition for now we might say "Where possible, entities should be in the plural form."

PS In Martin Fowler's REST maturity model article all entities are plural (Level 1 onwards).

Andrew's point is a good one that resolution is based on automatic resolution. Messing around with that feels like it may add more complexity than it's worth.
Also, thanks for the extract context Ruslan

In REST APIs, entities are usually in plural. E.g. using /courses/<courseid> is the standard way to obtain a course. As mentioned previously, you should read it as "get from the selection of courses".

But as it was also mentioned, this adds complexity because there is no easy way to pluralise an entity name that isn't in plural. E.g. what is the plural of mod_data? How can we detect if an entity is already in plural form or not?

We could let entities specify a "plural form" to be used, but this can lead to conflicts between different components. E.g. imagine that mod_data and mod_database (in case it existed) both define "databases" as the plural form, we would have a conflict there.

So I guess the best solution is to just calculate the name automatically and use it as it is. So it would be /course, /grade, /user and so on.

The question then is: do we want to recommend people to use plural forms in their folders/components from now on? Because I guess we won't migrate existing components to plural (e.g. move code from /course to /courses), so if we recommend using plural form we'll end up with a mix of singular and plural names. Actually, we'll already have a mix because some folders like /blocks or /notes are already in plural 😅

That's exactly why I think singular makes more sense: course/list is a list of course objects. course/1 is to get/update/delete course 1. Now that does mean that you would have to resolve the endpoints in a specific order so that 'list' is not treated as a course identifier such as idnumber. The simplest way to avoid this artificial limitation while avoiding namespace conflicts needs to use namespaces. Namespaces might seem ugly, but it's for programmers and computers, and both might be convinced of the simplicity gains. So instead: core_course/courses/list and core_course/course/1. mod_data/databases/* and mod_database/databases/* endpoints are therefore separate. The full frankenstyle name seems like a good preexisting namespace option to leverage.

In this case, the term "section" refers to the entity, correct? Then, based on the earlier advice about plural entities, shouldn't it be "sections" in the plural form?